Subject: loop prevention with loop detection

From: Choon Lee <[email-masked]>
Date: Thu, 13 Jan 1994 16:56:35 -0800

Hello, all,

I will try to address the issues that were raised in the loop 
prevention SIGlet meeting at the last AIW.

Please comment on the viability of this proposal. I intend to 
draw up a more detail description of this protocol, and any
major flaw that you can detect early will definitely help a
great deal!

	|                                |
	|  |-----|             |-----|   |
	|--|  J  |-------------|  K  |---|
	|  |-----|             |-----|   |
	|                                |
	|  |-----|             |-----|   |
	|--|  L  |-------------|  M  |---|
	|  |-----|             |-----|   |
	|                                |
     LAN segment A                    LAN segment B

(1) When a CANUREACH SSP message is received, hold on to it and
    send out a loop-detection packet onto the LAN (much like
    the "enforcer" packet that I described at the AIW).

    A timer is kicked off when the loop detection request is sent out.
    If no loop detection response come back before this timer
    pops, then it can send out the TEST command frame (DLC_START_DL).
    If loop detection response(s) is received, then a HALT_DL SSP 
    is sent to its DLSw partner.

    A loop detection response is sent out by another DLSw on the 
    same LAN segment if it has already received a CANUREACH with
    the same Data Link IDs and has a larger IP address_pair. A
    3-way hanshake is probably needed to ensure that the two
    DLSw are in sync as to which DLSw can allow circuit to be
    established.

    There are 2 advantages to this:
    i) the TEST packet need not be modified as before; thus
       alleviating the problem of having to "mix" the necessary
       info with the data that may exist in the TEST frame.

    ii) This approach can also be used in the event that NETBIOS_NR
	is received. The NB_Name_Query frame is sent out after
	the loop detection timer pops. (Netbios datagrams like
	ANR will be dealt with later).

    This method of loop prevention is reactive rather than pro-active.
    A slight drawback is that session setup would incur additional
    delay (should be set to a small value).

(2) Timing problem. If one of the parallel DLSw link is much slower
    than the other, then the TEST response (DLC_DL_STARTED) may arrive 
    (e.g. at M in the diagram above) before the CANUREACH is received.

    This would not be a problem if 2 things happen:
    i) The event (DLC_DL_STARTED) is ignored - seems to be the case
       in RFC1434.

    ii) The Data Link IDs (both Dest and Src) need to be remembered,
	so that when a CANUREACH with the same Data Link IDs comes
	in later, it can respond with a HALT_DL. Of course, we need
	a timer to help it "forget" the Data Link IDs after a while
	so it does not reject the CANUREACH forever.

(3) Netbios UI frames. To avoid these frames from infinitely looping,
    I suggest borrowing the address learning scheme from bridging.

    Whenever a Netbios UI frame that is destined to the NB_Group_address
    (i.e. NB_Add_Name_Query, NB_Name_in_Conflict, NB_Add_Group_Name_Query)
    is received, the source address, and which interface that it is
    received on are remembered. When another such Netbios UI frame
    is received on another interface, the frame does not get propagated.
    Of course, each of this address would be "unlearned" after some
    time.

    Note that this "learning" is done by the DLSw stack and is solely to 
    suppress the forwarding of frames in various directions, and is not
    meant to be used by the "bridge cache" of the underlying hardware for 
    its filtering mechanism.

Looking forward to your comments, any comment.

Regards,
Choon Lee